IBIS Macromodel Task Group Meeting date: 08 May 2018 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft: Walter Katz Todd Westerhoff * Mike LaBonte SPISim: * Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Mike L. noted that he wanted to briefly discuss some questions about BIRD187 and BIRD188. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Bob: Motion to approve the minutes. - Arpad: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Quality group's question regarding BIRD187 and BIRD188: - Discussion: Mike noted that BIRD187 was a clarification BIRD "Format and Usage Out Clarification." The discussion in the Quality group related to the "Increment" and "Steps" AMI Formats. These are like "Range" except Increment specifies the delta between steps, and "Steps" specifies the number of steps that spans the range. BIRD187.3 specifies that the sign of "delta" in the Increment shall be positive. Mike noted that the ibischk code allows deltas to be anything non-negative. Mike noted that if min and max were not equal then a delta of zero would never get from min to max. Arpad noted this was similar to a recent discussion about whether to certain BIRD158 parameters should explicitly state > 0, and that we had decided not to change the spec language to address all possible non-sense models. Mike asked if the behavior of the parser should be changed to disallow zero. Arpad noted that if min and max could be the same then zero could be a valid delta. Radek noted that the only problematic case was if min and max were not equal and delta were specified as zero. He noted that particular case should be caught and flagged as an error. Bob and Mike noted that the new language of BIRD187.3 says "the sign of delta shall be positive" which could leave open the possibility that the value is zero, where the original language had specified positive value (implying zero was invalid). Arpad noted that neither BIRD187 nor BIRD188 were yet in the spec and asked what we needed to do. Bob and Mike suggested that it could be handled by an editorial change to clarify BIRD187.3's use of "sign" and make it clear whether or not a zero delta was allowed at all. Review of Topic bin list: - Discussion: Arpad noted two new topics to consider for this list. He asked if the EMD topic should be taken up by ATM or the Interconnect group. Randy said it was best handled in the Interconnect group and could be picked up as soon as BIRD189 was finished. Bob agreed and emphasized it would be taken up after BIRD189 was completed. Arpad agreed to remove it from the ATM agenda. Arpad noted that the term "port" had been used in the VHDL-AMS sense in the [External Model] and [External Circuit] sections. He noted that this use of port was quite different from what EEs think of as ports. He asked if the "port cleanup" task to address this language inconsistency could be handled as an Editorial task or needed further discussion in ATM. Radek said he thought ATM could provide its input/opinion on the topic to the Editorial group, and it could then be handled as a strictly editorial matter. Bob thought we needed to review it more carefully in ATM first to make sure we didn't miss or introduce other inconsistencies. He also suggested we might just leave it as is and not address the language inconsistency. Bob noted that it would not be strictly editorial in the search-and-replace sense. He said he preferred a full BIRD for this task that would identify all changes to text, figures, etc. He noted that the Editorial group might be able to deliberate and create the BIRD, it did not have to be done in ATM. Arpad agreed it could come back to ATM if further technical changes were required, and noted that the Editorial group typically did not create BIRDs. Arpad said the minimum requirement, if we chose not to tackle the entire cleanup, would be to explain that we currently use the term "port" with two different interpretations. The group expected this work would not be part of 7.0. Arpad suggested reorganizing the bin list and placing the highest priority items on top. Radek suggested that "Allowing Terminator as a model_type for IBIS-AMI receivers" could be moved to the top of the list, as it could likely be handled quickly. It was moved to the top of the list, but Michael M. and Bob noted that it might not be a quick one-liner as some envisioned. Arpad asked if the two topics "Removing single-ended input threshold requirements for differential buffers" and "Removing single-ended characterization load requirements for differential buffers" should be moved up along with the "Terminator" topic. Bob said this would be a big discussion because it changed IBIS tradition in the sense that it would make earlier IBIS models not upgradeable (a simple update of the version would cause them to be non-compliant). Arpad asked if the threshold changes were required for the Terminator as AMI model_type topic. Michael M. said that we needed to discuss the differences between Terminator and Input, but that these two topics were not required in order to address the Terminator issue. These two topics address the need for more useful thresholds for differential buffers. Bob noted that IBIS historically made compromises and left certain keywords required even if they weren't strictly necessary. For example, [Ramp] is still required even if waveforms are available. He said this was done to avoid having confusing syntactical logic necessary to decide when things were or weren't required. Michael M. said these changes would not be easy. Randy noted that he was willing to continue discussion on the new C_comp proposal at any point, and noted that he would like to make sure people have time to focus on it (after BIRD189). Arpad asked how urgent this topic was. Michael M. said it was important, especially for single ended buffers. Randy agreed and said he wanted to get it into the first 7.x version. Bob agreed and noted that now that "terminals" have been clarified in BIRD189 we can revisit this proposal. Michael M. noted that he thought this topic would also get bogged down in referencing discussions. He noted that the clarifications on referencing topic would be useful for this topic, though he wanted the clarifications topic to stay at the bottom of the list. This new C_comp topic was moved to second on the list. Arpad asked about the "Guidance for power-aware vs. AMI models" topic. Michael M. asked if there is a way to include some non-LTI information, such as ISSO data, in AMI. Randy said this topic would need a lot more input from people investigating DDR5. He noted that power-aware is more important for people looking at single-ended signaling with equalization (e.g. DDR5). Arpad asked if that was the point of this topic. He noted that he thought the topic hadn't been proposed for that reason, but had been proposed so that we would clarify that you shouldn't expect ISSO, etc., to be used in AMI simulations. Arpad noted his response to an email question asking about using ISSO with differential buffers. His answer had been that ISSO keywords can't be used with true differential modeling. Michael M. said we need to explain how they interact. This topic was left below the single-ended items topics. The FEC topic was renamed to "IBIS AMI post simulation processing" and moved to the bottom of the list per Mike L.'s suggestion. Michael M. said he could discuss the first topic (Terminator in AMI) next week. Tabled Topics: - Discussion: The group briefly reviewed the tabled topics. Item 9 (new C_comp) was removed from this list since it is now a priority topic (above). Randy noted that Item 10 (single-ended AMI) will likely come up later and should not be removed. Bob and Radek said item 11 should stay. Arpad suggested 12, 13, and 14 (all related to Redriver flow) should stay. Arpad noted that he would keep item 15 as well, though it is low priority. All items remained except item 9. - Radek: Motion to adjourn. - Mike L.: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 15 May 2018 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives